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A VISUALLY ORIENTED COMPUTER IMPLEMENTED APPLICATION DEVELOPMENT 
SYSTEM UTILIZING STANDARDIZED OBJECTS AND MULTIPLE VIEWS 
This is a continuation application of U.S. Application Serial No. 08/340,702 filed 
on November 16, 1994 for which a notice of allowance was issued on January 7, 
1998. A software appendix is attached to this application. A portion of the disclosure 
of this patent document contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile reproduction for non-infringing 
purposes by anyone of the patent document or the patent disclosure, as it appears in 
the Patent and Trademark Office patent file or records, but otherwise reserves all 
copyright rights whatsoever. 

FIELD OF THE INVENTION 

This invention relates to the use of a computer implemented application 
development process, and, more specifically, to an authoring system and its 
associated run time system which permits the creation of an application (program) in 
which standardized objects are incorporated into the application without the necessity 
of the user having knowledge any programming language or programming script, and 
in which the application development process can be monitored (observed, evaluated, 
etc.) through the multiple synchronized views of output display, timing sequence, 
logical relationships, and script workform. 

BACKGROUND OF THE INVENTION 

The last ten years has seen an explosive growth in the development of digital 
computer systems and technology both in the processing power and of the hardware 
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systems and in the sophistication of the controlling software. Not only has the 
microprocessor become a ubiquitous incident to almost every laboratory, industrial, 
and household appliance, but many functions once assigned to combinations of 
moving parts are almost invariably now preformed by digitally controlled electronics. 
Systems as diverse as automobile ignition systems and home turntables now share a 
common electronic heritage. In fact, the performance of many electronic circuits can 
be equally implemented by hardware or by a digital computer under software control. 
In many instances the software component of the digital electronics has become 
enormously complex and correspondingly expensive to develop. Indeed, the cost of 
the electronic hardware has come down so far that the development time and cost of 
the software is now the limiting element in the introduction and pricing of many new 
systems. There has developed, therefore, a great need to reduce the cost and time 
of software development. 

The development over the past three years of what is referred to as 
"multimedia" computer systems has increased the complexity of the required software 
as the systems access, simultaneously present, and then replace vast amounts of 
information. Present systems are directed toward the simultaneous presentation of 
audio and visual output, but systems are clearly on the horizon which will present 
coordinated output which can be sensed by all five human senses and create a virtual 
reality. While present systems access the information for multimedia presentation 
primarily from local magnetic and optical storage media, it is foreseeable that 
electronic and optical communication with the world through the coming "information 
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superhighway" will provide a rich source of interactive multimedia 

In an attempt to reduce the cost and complexity of developing sophisticated 
software, attempts have been made over the last few years to modularize software 
functions with the idea that such modularized software could then be integrated into 
larger systems to achieve more complex functions. Each piece (object) of modularized 
software would consist of a set of instructions designed to perform a specific type of 
task which was frequently required in a more complex program. To use the objects, 
no knowledge of their internal coding structure would be necessary. All that would 
be required is to provide the modules with the information (parameters) they required 
for their use. Thus, applications would be built by selecting appropriate software 
modules and assembling/ordering/sequencing them to achieve higher order functions. 
This is the essential goal of "object oriented programming". It quickly became 
apparent that building with modularized software would not be efficient unless the 
presentation of the modules themselves conformed to some form of standard; ie., flat 
bricks of any material can be stacked, mixed flat and curved bricks, no matter what 
material they are made of, do not stack well. A second problem facing object oriented 
programming is that efficiencies of application construction would only be achieved 
when the assembly of the objects did not require extensive and complex programming 
itself. 

Several attempts have been made, therefore, to develop visually oriented 
programming systems in which software modules are manipulated as icons which may 
be arranged/ordered as needed and interconnected with logical operators. Examples 
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of this can be found in the NeXT application development system, in the VIP 
Macintosh program, and in PowerBuilder, a Microsoft Windows program. Generally, 
in these types of application development systems, the software modules or objects 
are presented on a palette from which they are selected and "dragged" into the 
application under development. Ideally, in these systems, the software instructions 
needed to integrate the objects into a functioning whole (corresponding to the visual 
representation or map) are provided by the authoring program system. In reality, most 
of the prior art systems require the user to write some of the interconnecting software 
code either in a common higher order language or in a language specialized to that 
program. 

It was hoped that the demand for complex and varied software imposed by 
multimedia programming requirements could be efficiently addressed by the use of 
object oriented programming. Until the present invention, these hopes have not been 
realized. A major problem not solved by the prior art has been the inability to handle 
in one visual, non-scripted, application development system the diverse requirements 
of different types of data required by a multimedia program in appropriate visual 
interfaces. 

For instance, during the authoring process a view of the output generated by 
the application under development is useful when dealing with visual output (images). 
However, such a view is much less useful for dealing with audio output since, clearly, 
audio can not be seen. Correspondingly, a time line view in which the elements of the 
application program are represented by graphs plotting the relative times and 
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sequences of presentation is much more useful for audio. Similarly, a logical map 
(flowchart paradigm), which visually relates the sequence and logical interconnections 
of each program element (visual, audio, etc.) is very useful for designing and following 
the basic structure of the application program. Sometimes, for quickly manipulating 
or editing particular parts of the developed application code, it is more useful to be 
able to view the program in a text view and treat the underlying script like a text 
document. Not only should the application development system provide, at any given 
moment, a view appropriate to the type of multimedia material being utilized, but such 
views should be able to be synchronized so that changes made in one view are 
instantly reflected in all the others. 

Prior art application development programs do not have the flexibility to present 
all four views, much less in a synchronized manner. Programs are available which are 
optimized for output view, map view, timeline view, and script view. Some permit 
more than one view with some synchronization. However, no prior art program 
permits access to all four synchronized views. In particular, no prior art program has 
successfully overcome the difficulty of simultaneously synchronizing the time line view 
to the other views. 

Additionally, in an optimum visual, object oriented, application development 
program there should be available a wide variety of objects (software modules that 
would manipulate in different manners multimedia output) with the ability to easily add 
additional objects, developed by independent programmers, to the development 
system. Each added object should seemlessly be integrated so that it is available in 
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all four views. Programs of the prior art each have their own object definition 
standards. That is, for an object to be incorporated into their system/ it must meet 
that program's standards. No prior art program is available which will allow addition 
of objects not designed to its standard without the necessity of writing additional code 
to perform the interface to that object. Finally, it should be noted that application 
development systems necessarily consist of two major parts. The first is the 
authoring section which provides a customized output (script). The second is a run 
time system which takes the customized output and executes it. Some prior art run 
time systems for visually developed applications are notoriously slow in their 
execution. 

SUMMARY OF THE INVENTION 

The present invention overcomes the limitations of the prior art. First, the 
system can be used to author applications using an entirely visual programming 
scheme (paradigm) which does not require the user to know or be able to write any 
specialized code. Icons representing the objects (and accordingly their functionalities) 
may be placed (dragged) into an appropriate view. The system of the invention 
generates the information needed by the run time program. Second, during authoring, 
the user can access all four views which can be synchronized or not at the user's 
choice, and these views are available in overlapping windows. The user may, thus, 
work in the view most appropriate to the type of object the user is manipulating. 
Third, the objects which are available on the palette, can be added or subtracted from 
the development program with great ease. While the present implementation of the 
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invention is designed to directly operate standardized Microsoft Visual Basic VBX 
controls as objects, the manner in which the invention wraps the objects is equally 
usable with objects written to standards other than the Microsoft VBX control. 
Fourth, the invention is capable of utilizing any objects written to a standard 
5 specification. That is, at its core it is featureless and extensible. The invention 
imposes no limitation on the type of function the objects can preform, and the objects 
need not be directed towards multimedia or any other single use'. Thus, all types of 
programs can be developed utilizing the entire range of available objects, and, during 
application development, the objects may all be presented in the four views, once 

O 

10 3 again synchronized or not. Fourth, a run time program is provided which executes the 

[i 

133 output of the authoring program much faster than the run time programs of the prior 

=P 

^ art. These, and other advantages of the invention will become apparent from the 
] r " description of the invention which follows. 

Z BRIEF DESCRIPTION OF THE FIGURES 

Q 

15jy Figure 1 shows a schematic representation of the major components of a 

M modern programmable digital computer. 

Figure 2 shows a Map view of a simple program. 
Figure 3 shows a Multitrack view of a simple program. 
Figure 4 shows a Workform view of a simple program. 
20 Figure 5 shows for a simple program all four views, Output, Map, Multitrack, 

and Workform simultaneously displayed in separate windows. 

Figure 6 shows a typical palette displaying the objects which are available to 



MORRIS & DENTON 



the user of the system. 

DETAILED DESCRIPTION OF THE INVENTION 

Definitions 

In order to avoid the confusion often present in the world of computer jargon, 
for purposes of this application, the following terms shall have the meanings set forth 
below: 

"APPLICATION" shall mean an end product computer program which is ready 
for use by its intended audience. 

"CODE" shall mean a series of specialized words and symbols in a particular 
syntax which must be entered through a keyboard and which is then converted to a 
machine readable form. 

"OBJECT" shall mean a modular software program written to a defined 
specification which may perform any function. For purposes of this application, the 
word "OBJECT" shall be considered synonymous with the term "custom control". 
Objects are intended to be grouped and assembled into applications. 

"SCRIPT" shall mean a set of computer instructions written at a higher level 
than code ie., farther removed from machine language, which is usually interpreted 
during execution. "SCRIPT" for purposes of this application shall also refer to the 
listing of objects and property settings generated by the authoring program of this 
invention. 

"SYSTEM" shall mean the computer implemented application development 
system of this invention. 
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"WINDOWS" (when appearing in all capital letters) shall mean the Microsoft 
operating system of the same name without regard to the version number. 

The present invention is an integrated computer implemented application 
development system which permits the user to create custom applications without 
writing a line of computer code. The ability to do just this has existed as a dream 
since computers moved into the public imagination and the dream is fulfilled by this 
invention. The invention provides a fully visual programming environment in which 
the user can create powerful WINDOWS applications in hours that would take days 
or weeks using standard programming languages. When describing the process 
implemented by a non-authoring computer system, it is generally sufficient to describe 
the process steps carried out and their order. However, authoring programs create an 
environment with many potentialities within which the user works to develop the 
application. To describe authoring programs it is necessary to describe the 
environment. Consider the analogy to building a house. The environment provides 
the tools (hammers, nails, saws, lumber, wires, pipes, etc.) as well as ways of looking 
at the house under construction (architectural plans, outside drawings, kitchen 
layouts, etc). Once the environment contains all the tools and views needed, the user 
can construct the house according to his/her own needs by assembling the parts. 

This description of the computer implemented application development system 
will briefly: 1) describe the environment created by the present invention; 2) describe 
the process of using the system to create applications; 3) describe the manner in 
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which the system creates a script corresponding to the program elements and how 
that script is used by the run time program; and 4) describe how the system 
coordinates objects and permits additional objects to be added easily. A complete 
description of the invention is contained in the source code provided in the software 
appendix which is attached to this application. 

Figure 1 is a block diagram showing the basic functional units of a modern 
digital computer with which the computer implemented applications development 
system of the invention works. Information may be stored on magnetic or optical 
media for access or be available through a connection to a remote information source. 
During the development of an application with the system of this invention, the user 
directs the incorporation of objects into one of the four views, modifies the properties 
associated with that object, and interconnects the objects so chosen. The user may 
direct the machine to accomplish these tasks using a pointer (such as a mouse) or a 
keyboard and visually observes his/her actions on the system's output display. As the 
system responds to the user's directions, it creates a script representing the 
application being developed by the user. When the development process is complete, 
the user stores the script on one of the system's storage devices. 

One of the interesting features of the object oriented authoring system of this 
invention is that no traditional looking code, written in a programming language, is 
generated by the system. Rather, the output of the authoring system is a listing of 
the objects in order of appearance (in the program sequence) along with the properties 
associated with that object at that place in the sequence. The properties are the 
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information or settings which specify to the object how it will perform. The computer 
implemented application development system records the settings for the objects and 
the order of execution of the objects in an output script. Thus, the system operates 
only at the object level. As the author proceeds in developing the application, the 
system adds to the script. 

The four views are different ways to make and look at the same script. Each 
has its own special perspective and strength. Figure 2 shows a Map view of a simple 
program in which the flow of the program and the flow of data is displayed. The Map 
view displays a block diagram in which the authored program is viewed as the 
sequence in which the objects are utilized, the branches which are taken, and the flow 
of data between the objects. The system not only allows the passing of data back 
and forth between different objects, but allows objects to affect each other in other 
ways as well. The Map view is best for seeing and building the program using a 
flowchart metaphor. Thinking of the program in this way can be very useful when 
building interactive applications since this view presents a way to see the flow of data 
between objects which can save hours of debugging time. When a Map window is 
opened, the system generates the Map view directly from the underlying script. 

The Output view displays the screen output of the objects and is best for 
working directly with the product of the script. In this view you see the output of 
each object you incorporate into the program. When an Output view window is 
opened, the system generates the Output view directly from the underlying script. 

Figure 3 shows a Multitrack view of a simple program in which the timing 
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sequences of object presentation are displayed. The Multitrack view is limited to 
coordinating and timing the appearance, disappearance, and activities of the objects. 
It is different from the other views because it is not a view of just any part of the 
script (program), it only views timed sections. This view is useful for creating parts 
5 of the application that require objects to be created and destroyed at specific times. 
The Multitrack view automatically sets all the special properties that differentiate the 
objects in these time sections form the objects in other parts of the application 
(script). 

Figure 4 shows a Workform view of a simple program where each object and 
10 S its associated properties is displayed in each row. The Workform view displays the 
m underlying script directly and permits treating it like a text document. The script can 
Ni be viewed in as little or as much detail as is necessary. This view has word 
processing features so that it becomes easy to make global changes, and to copy and 
move blocks of information. 
15 n] Figure 5 shows for a simple program all four views, Output, Map, Multitrack, 

03 and Workform simultaneously displayed in separate windows. In each view, the 
system of this invention permits development of the application using the same 
method of adding an object, interconnecting the object, and setting the objects 
properties. For instance, from a palette of objects, which displays a collection of icons 
20 that represent each object available to the system (such as the palette shown in Figure 
6), the user of the system drags an object into the view. The system simultaneously 
generates the underlying script which reflects the object and the properties associated 
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with the object. The user's double click on the icon representing the object presents 
a menu list of the properties for that object the settings of which can be changed 
according to the user's requirements. If a separate dialog box is available for a 
particular property, clicking on the property gets the user to the dialog box. As a 
property setting is defined, the system records that definition in the associated 
underlying script. In addition, the system user can elect to have all the four views 
synchronized so that each view is updated for every change made in any view to the 
underlying script. 

For example, in the Output view window the user might drag an icon 
representing an object which pulls a picture into the application program. The Output 
view window would then display the picture. If several pictures were to be presented 
in some order, several picture icons would be placed in the output view window. The 
user could set the order of presentation in the Workform view, but might more 
graphically do so in the Map view. In the Map view the user could arrange the picture 
icons in the order in which he/she wished the pictures to appear. In addition, in the 
Map view, the user could add conditional branches from picture to picture. The 
display timing for each picture could be set through the properties boxes or the 
Workform view, but might more graphically be done in the Multitrack view where each 
pictures duration and sequence would be indicated on parallel time lines. Finally, if the 
user wished to duplicate part of the application already created, he/she could use the 
Workform view to copy and move the underlying script. Clearly, the user of the 
system has the option of choosing the view most appropriate to the type of 
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application under development. Since the system is a general purpose programming 
environment, the user will choose the view most appropriate for the application. 

It should be noted that a very powerful feature of the Map view resides in its 
ability to permit the application developer to specify that one object in the sequence 
5 get or set data from/to another object. Thus, information exchange among objects is 
enabled as well as logical branching and program flow between objects. 

In order to run a program developed in this manner from the script created by 
the authoring system, a run time program is required which executes each object in 
the defined sequence with the defined property settings. The system of this invention 
10 i-Q provides such a run time program. Programs authored by the computer implemented 



Kj application development system of this invention run faster under its run time program 
./\ than to object oriented programs developed and run under Microsoft Visual Basic. 



U is able to integrate and work with the objects in the above described manner because, 
1 5 iy in addition to the internal properties which are unique to each object and relate to the 
W special work that each object does, the system wraps all objects in a kind of 

"envelope" of special properties that regulate how the objects act in the system. 

These special properties are: 



The computer implemented application development system of this invention 



BranchTo 



Kill 



20 



Break 



Label 



Comment 



TimeMark 



Create 



Track 



MORRIS & DENTON 



Create Type 



Type 



Destroy 



WaitFor 



Destroy Type 



Group 



No other program in the prior art wraps standardized objects in this manner to achieve 
5 similar functionalities. This wrapping is also what permits the easy integration of 
additional objects into the system. Also, the system is so designed that the number 
of such special properties may be increased, if necessary, to adapt to any changes in 
future definition of objects. 



10 ,0 which have been devised by the proponents of object oriented programming. Many 
S3 prior art authoring systems use objects with their own proprietary standard. However 
'/* , the implementation of the authoring system of this invention disclosed in the 
;f " software appendix has been designed to operate with " VBX custom controls" (objects) 
U written to the Microsoft Visual Basic and Visual C++ standard. Presently, there are 
15 ID about 300 software vendors across the United States developing and selling such 
R objects. Thus, a large number of objects written to the same standard are now 
available. The Microsoft Visual Control Pack contains representative objects and 
examples of code for different control types. Any object written to this standard may 
be used with the system of this invention. However, the methods employed by the 
20 present invention to wrap objects and integrate and run them directly from the system 
are equally applicable to objects written to other standards, and the scope of the 
present invention should not be considered limited by reference to the VBX control 



As noted earlier, there are many different standards for the format of objects 
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type object. 

The source code in the software appendix does not contain any objects. As 
noted above, objects may be obtained through a large number of commercial 
suppliers. However, the system of this invention is sufficiently general to permit 
development of applications of all types. Specialized applications may be developed 
by importing appropriate standardized objects into the system. Thus, the system is 
infinitely extensible since it provides the necessary backbone environment for 
application development with objects written to a common standard. 

While the software appendix discloses the source code for the computer 
implemented application development system of this invention in the WINDOWS and 
IBM-PC platform, the invention is not platform dependant and could also be 
implemented on the Macintosh and other platforms. In order to run the source code 
disclosure of this invention on a digital computer, the following commercially available 
software programs should be available on the computer: Microsoft Visual C+ + 1.5, 
Microsoft WINDOWS 3.1, and objects of the user's choice written to the Microsoft 
VBX Custom Control standard, Version 1.0. For Microsoft Visual C+ + 1.5, file 
VBAPI.H has been renamed to VBJVBAPI.H. 

The computer implemented application development system of this invention 
is presently available from V GRAPH, Inc. under the trademark OZONE. 

As noted above, standard objects may perform any function and can be utilized 
by the general purpose programming environment of this invention. Integration of 
these objects is achieved by wrapping the object with additional properties and 
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permitting the user to assign values to the new properties as well as assigning values 
to the properties required by the object. The run time system manages the objects not 
only by transferring data from and to the objects as specified in the program structure, 
but also by looking ahead at the property values associated with an object so that it 
5 may do what is necessary to properly initiate the object. Thus, an instance of the 
object is created without any additional outside code being required simply by 
specifying the property values required by the object. 

Since an object may perform any function, the objects may contain any of the 
normal programming constructs found in programming languages including, but not 

u 

10 ,J3 limited to, functions such as "if then" and other conditional looping. Since these 

!«*' 

C3 constructs are in objects which are integrated into the final application, the system of 
this invention permits unlimited expansion of program capabilities; that is, it is 
infinitely extensible without the user of the system writing any code. Also, since the 

i * 

U system of this invention places no restraints on the nature of the objects which may 

tats. 

15 nj be implemented, even objects utilizing entire sublanguages are easily added. 

W A remarkable consequence of the fact that the system of the invention permits 

standard objects to be placed in a timeline is the fact that software applications 
performing parallel processing may be developed just as easily as other types of 
programs without the necessity of writing any linking code. Objects placed on the 

20 timeline and performing different tasks can be logically integrated and instantiated 
(timed communication and/or data flow) at any time relative to each other by the 
system of the invention. This feature of the system permits objects performing 
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different functions to operate independently or in conjunction with each other without 
the requirement of writing specialized parallel processing timing code. The application 
development system of the invention contains all requisite functionalities necessary 
to instantiate, integrate, sequence, and provide communication between standardized 
object performing any type of task. 

An alternative way to view the run time program of the present invention is to 
view it as a software container that displays and executes programmable objects 
based on a script that contains a listing of property values. The script is separate from 
any executable code and is interpreted by the container. This interpretation provides 
for the communication of data between objects and the timing of those objects. The 
script may come to the container from any manner of electronic storage including but 
not limited to hard drive, network server, or removable electronic storage device. The 
script and container combine to allow for interaction with an end user who may cause 
the loading of new scripts into that container, thus causing new objects to be 
executed within that container. 
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